The Lost Stakeholder Analysis Dimension: Engagement

Jarett Hailes — Fri, 19 Feb 2010 03:13:00 GMT

Stakeholder Analysis is an important and often ongoing activity that Business Analysts perform as part of their duties. Solution delivery team members need to understand who else is involved or impacted by their work effort, how they can interact with these people or groups, and what sort of tradeoffs exist in pleasing one group over another.

The BABOK highlights several important dimensions that can be collected on each stakeholder, namely:

The stakeholder’s attitude towards the project or solution team

The stakeholder’s influence on the project or solution team’s success

The type of stakeholder (internal/external, direct/indirect, etc.)

The body of knowledge also describes artifacts such as a RACI chart and stakeholder map to help manage the information you collect on stakeholders.

In addition to these dimensions, I believe that there is another consideration that needs to be included in stakeholder analysis: the stakeholder’s engagement level with the project or solution team.

A stakeholder’s engagement level describes the expected or actual amount of involvement a stakeholder has with the project. Since the required level of engagement with certain stakeholders may differ over the course of a project, this level should represent the level of engagement relating to activities that could or should involve the given stakeholder. In some cases, you may wish to separately track the expected/needed versus actual amount of engagement.

This is an important dimension to consider for several reasons:

The level of engagement that a stakeholder provides can greatly impact the amount of effort required to perform other Business Analysis activities, including requirements gathering/validation, solution assessment, enterprise analysis, etc.

If you expect to see high levels of active engagement from certain stakeholders who may not be considered high priority in the overall context of the project, you may find that the team will spend a disproportionate amount of time dealing with these stakeholders. By identifying such potential issues up front mitigation strategies can be developed to ensure that efforts are focused on where the highest needs are.

Conversely, if you identify high priority stakeholders with likely or actual low levels of engagement the team can identify potential solutions to address the causes of such disengagement, escalate this issue with the sponsor as needed, or allocate sufficient time to ensure that these stakeholders’ needs are still adequately met.

The Engagement Gradient

Every stakeholder’s level of engagement can vary. I use 4 markers as generic signposts to describe the general level of engagement each stakeholder has.

Proactive: these stakeholders are heavily involved in project activity. They are not only willing and able to answer questions, but they’ll ask you questions you haven’t thought about yet. They want to trial out potential solutions, volunteer for committees and the like. Generally they behave as an active team member rather than a stakeholder.

Responsive: these stakeholders get involved in the process, but only when prompted. They will respond to surveys, join in interviews or workshops, and provide suggestions to outstanding items but they won’t go out of their way to let you know something or volunteer to actively work on issues.

Marginal: these stakeholders will participate on occasion, but not all the time. They will provide limited feedback, give short responses, not really contribute meaningfully to discussions or suggest solutions to problems. Such stakeholders can quite often feel obligated to be involved (although if this is the case it should be documented separately in the attitude section).

Disengaged: these stakeholders you rarely or never hear from. They will not respond to meeting requests, surveys, etc. When they are present it’s virtually impossible to get them off their Blackberries or do anything beyond nod their head (either in agreement or disagreement).

You may find that some stakeholders exhibit various markers depending on the subject or issue at hand within a project. If appropriate you may have a matrix of engagement levels for your stakeholders with the stakeholders and the various aspects of your project representing the axes.

Leveraging Engagement in Stakeholder Analysis and Other Activities

By bringing in the engagement level dimension into your stakeholder analysis, you can now optimize your other Business Analysis activities much more efficiently. Taking this information into consideration in conjunction with the stakeholder’s attitude and influence towards the project can help identify potential risks to the success of the project, find potential bottlenecks in upcoming project activities and look for ways to improve stakeholder communications.

For example, let’s say that you have a stakeholder with a great attitude, is proactively engaged but of low influence to the project? Such a stakeholder could have the potential to take up a lot of the project’s time. Perhaps you can look to leverage their enthusiasm for the project by having them spread the word of the project, get other higher priority stakeholders on board, etc.

When a stakeholder is disengaged there could be several causes. If the stakeholder could pose a major influence on the project I try and determine whether the main reason is lack of time or lack of interest. If it’s the former then we can work on finding ways to involve them in more asynchronous activities or to get them involved at a higher level, if appropriate. If it’s the latter then I know the project may have a potential problem – perhaps the apparent value of the project is not there, or more work needs to be done to ensure this stakeholder sees the value and thus will contribute more to the project.

Looking at the overall engagement of all stakeholders can also give you an idea as to how well your engagement activities are being received. If it looks like most of your stakeholders are not very engaged with the project you may wish to review your communications plan as well as your other stakeholder activities and ask if you have had sufficient input in order to proceed.

It is important for a Business Analyst to acquire and deliver the right information from the right people and organizations within the course of their duties. Stakeholder analysis activities can help a BA navigate the sometimes challenging waters of ensuring that everyone has their voice heard and are sufficiently involved to ensure the project or solution is a success. Understanding the anticipated/desired and actual levels of engagement with stakeholders can help ensure that project goals are met.

Jarett Hailes
Larimar Consulting Inc.
http://www.larimarconsulting.com

The Dirty Harry Approach to Requirements, or “Are you Feeling Lucky, Punk?” Solve Problems First, Ask Questions Later - Part 1

ModernAnalyst.com — Sun, 25 May 2008 14:40:00 GMT

Have you ever had to use a map to get somewhere, and after navigating around the wilderness for hours, eventually had to ask for directions because it failed you?

Alternatively, have you ever read directions to assemble a toy, and rather than help you, the directions made things much more complicated?Perhaps you just figured it out on your own, without the directions.

This is what some BA’s and IT folks do all the time. They get understandable Business Requirements in hand, the bugle sounds, and IT is immediately restless in the starting gate. And they are off!Who will be the first IT hero to come up with a solution or the code which business will say yes!

In this kind of a race, there is never a finish line.The race will go on forever until all of the problems are solved; and in fact some of the problems are the results of other solutions. Finally, someone in IT draws a white line in the sand (creates a functional Design Document or something) and says to the business, 'is this ok?'If the business agrees, then the race is over. Now it's time for the next game.

Now we play a game of tag.The IT group starts coding the solution. After a while, an issue comes up and the IT folks tag a businessperson.“You're it”, say the IT folks. “When you have an answer, let us know.” (Back to Doom 10)

The businessperson comes back with an answer, and now the IT folks are tagged.This goes on until all of IT‘s questions are answered, or the business gets frustrated to a point and says, “Just do something.” As a result, someone in IT or the business erases the white line from the first game, and redraws the white line somewhere else.

Now if you’re lucky, the BA is so annoyed by this, that they says to IT, “Let's just get more precise requirements.The IT folks say no way. The business is already ticked off, and talking to them again will only tick them off more.We cannot start over, we must use what we have, and you need to sell it to them (or shove it down their throat) and make them like it. Speak their language; and it should be easy.

Therefore, the BA starts selling the solution (after finishing up his/her resume).This is where 'Do you feel lucky' comes in to play. We all know what happens from there.A two month project takes 1 ½ years and costs $1.5 million dollars and a death march.

The examples above are about being precise and understandability. Jonathan Babcock wrote a great article in his blog titled Good Requirements Are More Than Just Accurate. This is a great article; take the time to read it.

Now, since I got out all of my pent up aggression, I need a week to recover. Next week, in part 2 we will look at how we get precise and understandable requirements, and stop the games above.

By the way, I really do like IT folks. It's just that sometimes I don't like the way they do things.Ok, sometimes I hate the way they do things. In most cases, though, the IT folks are just trying to help the business, and that honorable intention is what gets us all in trouble some times...

Business Analyst Community & Resources | Modern Analyst

The Lost Stakeholder Analysis Dimension: Engagement

The Engagement Gradient

Leveraging Engagement in Stakeholder Analysis and Other Activities

The Dirty Harry Approach to Requirements, or “Are you Feeling Lucky, Punk?” Solve Problems First, Ask Questions Later - Part 1